Subscription billing app conflicts with IRS Forms ap#4668
Merged
ventselartur merged 1 commit intomainfrom Sep 3, 2025
Merged
Conversation
djukicmilica
approved these changes
Sep 3, 2025
ventselartur
deleted the
bugs/SubscriptionBillingConflictsWithIRSFormsApp
branch
miljance
pushed a commit
to miljance/BCApps
that referenced
this pull request
Oct 22, 2025
When Subscription Billing app creates a new billing document it validates the vendor number and posting date. Then the IRS forms app, which is the US specific app, not related to subscription billing, run an update of certain fields related to this app. This kind of update in the IRS forms app from the other side triggers the Subscription billing app code - the CreatePurchaseHeaderForVendorNo procedure. This procedure throws the following error: You cannot make this change because the document is linked to a contract. If you still want to change the field, first delete this document and then make the change to the contract. This procedure has a list of fields for exclusion. It would be great to add IRS forms app fields to the exclusion list, but that is not possible unless i create a dependency between these two apps, which does not make any sense. The other approach which i eventually chose is to skip calling the CreatePurchaseHeaderForVendorNo when i change the vendor number pr posting date. To me it sounds much better as we keep the procedure untouched, so we continue to call it whenever some user changes this value in the document. But if we validate the posting date through the code in the CreateBillingDocuments codeunit, we can skip this check. [AB#599229](https://dynamicssmb2.visualstudio.com/1fcb79e7-ab07-432a-a3c6-6cf5a88ba4a5/_workitems/edit/599229)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Subscription Billing app creates a new billing document it validates the vendor number and posting date. Then the IRS forms app, which is the US specific app, not related to subscription billing, run an update of certain fields related to this app. This kind of update in the IRS forms app from the other side triggers the Subscription billing app code - the CreatePurchaseHeaderForVendorNo procedure. This procedure throws the following error:
You cannot make this change because the document is linked to a contract. If you still want to change the field, first delete this document and then make the change to the contract.
This procedure has a list of fields for exclusion. It would be great to add IRS forms app fields to the exclusion list, but that is not possible unless i create a dependency between these two apps, which does not make any sense.
The other approach which i eventually chose is to skip calling the CreatePurchaseHeaderForVendorNo when i change the vendor number pr posting date. To me it sounds much better as we keep the procedure untouched, so we continue to call it whenever some user changes this value in the document. But if we validate the posting date through the code in the CreateBillingDocuments codeunit, we can skip this check.
AB#599229